Animated two-dimensional barcode checks

ABSTRACT

Systems and methods are disclosed to provide an animated 2D barcode check that is used to securely and efficiently transmit financial information between mobile devices. The financial information includes a check written by a payer and transmitted to a merchant. The check includes account information of the payer and of the merchant with a payment service provider, a payment amount, and a cryptographic signature that has been certified by the payment service provider. The payer&#39;s mobile device encodes the check into a sequence of 2D barcodes and displays the sequence of 2D barcodes in a loop that is scanned by a camera on the merchant&#39;s mobile device. The merchant uses the cryptographic signature to verify the validity of the signature on the check without having Internet connectivity to the payment service provider. The merchant may later present the check to the payment service provider to receive payment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patentapplication Ser. No. 13/168,671 filed Jun. 24, 2011, which is herebyincorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure relates generally to financial transactionsconducted via a user device. In particular, the present disclosurerelates to methods and systems for using animated two-dimensional (2D)barcode checks on a user device to facilitate payment transactions.

BACKGROUND

Mobile phones are increasingly being used in conjunction with on-linepayment service providers, such as PayPal, Inc. of San Jose, Calif. Withthe ever-increasing popularity of mobile devices such as smart phonesand of Internet commerce, both consumers and sellers are using mobiledevices to conduct financial transactions between parties, whether theyare individuals or companies. For example, a consumer may launch a webbrowser on a mobile device to connect with a payment service providerover the Internet to request an on-line payment. The consumer may accesshis or her on-line account, provide payment information, and authorizethe payment service provider to transfer funds from the consumer'saccount to a merchant's account. A confirmation message may then be sentto the consumer's or the merchant's mobile devices to complete thetransaction. However, to facilitate payment transactions, and to enablepayment transactions even when there is no Internet connectivity, it isdesirable for a consumer's mobile device to communicate directly with amerchant's mobile device. For example, the consumer may use the mobiledevice to transmit information such as his or her account informationand payment amount to the merchant's mobile device to authorize thepayment. The merchant may later connect with the payment serviceprovider for transmission of the information received from the consumerto complete the transaction.

While technologies such as near-field communication (NFC) and QuickResponse (QR) codes have been proposed for secure communication offinancial information between mobile devices, they suffer from variousdeficiencies. For example, NFC requires the installation of NFC-capablehardware and software on the mobile devices of both parties, thusincreasing cost for users. QR code is a two-dimensional barcode (2Dbarcode) that may be displayed by a mobile device and scanned by acamera on another mobile device to communicate between mobile devices.However, a QR code is limited in the amount of data encoded therein,making its use impractical for the transmission of large amounts of datathat may be encountered in a financial transaction. In addition, mobiledevices may vary greatly in display and camera capabilities, making itdifficult for a mobile device with a low resolution camera to accuratelycapture information encoded in a large QR code. Furthermore, accuratescanning of a large QR code may be time consuming and may requireperfect focus or alignment of the scanning camera with the display,further limiting its ease of use. Accordingly, there is a need for a wayto securely, easily, and economically communicate financial informationbetween mobile devices to facilitate financial transactions.

BRIEF SUMMARY

Systems and methods are disclosed herein to provide an animated 2Dbarcode check that may be used to securely and efficiently transmitlarge amounts of financial information using one or more mobile devices.In one embodiment, a consumer may encode payment information for a checkinto a sequence of 2D barcodes for display on the consumer's mobiledevice. The sequence of 2D barcodes may contain a cryptographicsignature of the consumer to authorize a payment from the consumer'saccount with a payment service provider to a merchant. The mobile devicedisplays the sequence of 2D barcodes in a loop to create an “animated”2D barcode that may be scanned by a camera on the merchant's mobiledevice to capture the payment information encoded therein. Because asequence of 2D barcodes is used, there is no limit on the amount of datatransmitted. Each frame of the animated 2D barcode may be made suitablysmaller, increasing the chance that the frame will be accurately scannedand decoded using a low resolution camera. Moreover, a small barcode maybe scanned faster since it is less sensitive to variations in focus oralignment of the camera with the barcode. The merchant may use thecryptographic signature to verify the validity of the signature on thecheck. The merchant may later present the check to the payment serviceprovider to receive payment. As a result, the consumer and merchant maysecurely communicate financial data without having Internet connectivityto the payment service provider. A user may also be able to convey largeamounts of data or information securely through a sequence of 2Dbarcodes, where each barcode in the sequence contains a differentportion of the data or information to be conveyed. Identifiers embeddedin the barcodes allow the device capturing the barcodes to startcapturing from any barcode in the sequence and to know when a completesequence is captured.

In accordance with one or more embodiments of the present disclosure, amethod for communicating data is disclosed. The method includes encodingthe data into a sequence of 2D barcodes, where each of the 2D barcodesis encoded with a partial amount of the data and a sequentialidentifier. The method also includes displaying the sequence of 2Dbarcodes sequentially in a continuous loop on a user device.

In accordance with one or more embodiments of the present disclosure, amethod for communicating data is disclosed. The method includes scanninga sequence of 2D barcodes displayed in a continuous loop on a displaydevice to generate a sequence of scanned frames on a user device. Eachof the 2D barcodes is encoded with a partial amount of the data and asequential identifier. The method also includes decoding the sequence ofscanned frames to reconstruct the data.

In accordance with one or more embodiments of the present disclosure, amethod for conducting a financial transaction is disclosed. The methodincludes certifying a public key. The method further includes receivinga payment instrument. The payment instrument includes the certifiedpublic key and information on a payer and information on a payee. Thepayment instrument includes data decoded from a sequence of 2D barcodes.The method further includes verifying the certified public key. Themethod further includes transferring funds from an account of the payerto an account of the payee.

In accordance with one or more embodiments of the present disclosure, anon-transitory computer readable medium having computer readable codefor execution by a processor of a user device to perform a method ofcommunicating data is disclosed. The method includes encoding the datainto a sequence of 2D barcodes, where each of the 2D barcodes is encodedwith a partial amount of the data and a sequential identifier. Themethod also includes displaying the sequence of 2D barcodes sequentiallyin a continuous loop on the user device.

In accordance with one or more embodiments of the present disclosure, anapparatus for communicating data is disclosed. The apparatus includes aprocessor. The apparatus also includes a camera. The camera is used toscan a sequence of 2D barcodes displayed in a continuous loop on adisplay device to generate a sequence of scanned frames. Each of the 2Dbarcodes is encoded with a partial amount of the data. The apparatusfurther includes a non-transitory computer readable medium havingcomputer readable code for execution by the processor to perform amethod. The method includes decoding the sequence of scanned frames toreconstruct the data.

These and other embodiments of the present disclosure will be more fullyunderstood by reference to the following detailed description of theembodiments when considered in conjunction with the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a flow chart of the steps to perform on a payer's and amerchant's mobile device to communicate payment information between themobile devices using an animated 2D barcode check according to one ormore embodiments of the present disclosure;

FIG. 2 shows a detailed flow chart of steps 103, 105 of FIG. 1 performedon a payer's mobile device for payer set up and signing keycertification by the payment service provider according to one or moreembodiments of the present disclosure;

FIG. 3 shows a detailed flow chart of steps 105, 107 of FIG. 1 performedon a payer's mobile device for generating the animated 2D barcode checkaccording to one or more embodiments of the present disclosure;

FIG. 4 shows a frame of an animated 2D barcode generated from a payer'smobile device according to one or more embodiments of the presentdisclosure;

FIG. 5 shows a detailed flow chart of step 109 of FIG. 1 performed on amerchant's mobile device to communicate with a payment service providerto register an account and to receive a certificate revocation list(CRL) according to one or more embodiments of the present disclosure;and

FIG. 6 shows a detailed flow chart of steps 111, 113 performed on amerchant's mobile device to scan and validate the animated 2D barcodecheck according to one or more embodiments of the present disclosure.

Embodiments of the present disclosure and their advantages are bestunderstood by referring to the detailed description that follows. Itshould be appreciated that like reference numerals are used to identifylike elements illustrated in one or more of the figures.

DETAILED DESCRIPTION

Systems and methods are disclosed herein for secure and efficientcommunication of financial information using a mobile device to transmitor capture an animated 2D barcode to facilitate financial transactions.The financial information may include a payment instrument such as acheck written by a payer and transmitted to a merchant to pay for goodsor services received. The check may include account information of thepayer and of the merchant with a payment service provider, a paymentamount, a cryptographic signature or a signing certificate that has beencertified by the payment service provider, and other secure informationused by the merchant to verify the validity of the check. The financialinformation is segmented and encoded into a sequence of 2D barcodes,such as QR codes, that is displayed in a loop as an animated 2D barcodeon the payer's mobile device. The merchant uses a camera on a mobiledevice to scan the animated 2D barcode to capture the financialinformation encoded therein. The merchant runs applications on themobile device to decode the financial information and to preliminarilyvalidate the check. Advantageously, financial information iscommunicated between the mobile devices without requiring Internetconnectivity to the payment service provider. The merchant may laterconnect with the payment service provider to present the check forpayment. Use of the animated 2D barcode enables secure transmission offinancial information that often exceeds the size limit of data encodedby a static or single 2D barcode. In addition, the frame size and theplayback speed of the animated 2D barcode may be tailored to suit thecamera resolution of the capturing mobile device to enable accurate andconvenient capture of the financial information. Animated 2D barcodesmay also be used to transmit financial information other thaninformation for checks, such as information for credit cards/debitcards, or gift cards to conduct payment transactions. It may also beused for a merchant to issue refund or credit back to the payer'saccount, or for other types of secure transactions.

Refer now to the figures wherein the drawings are for purposes ofillustrating embodiments of the present disclosure only, and not forpurposes of limiting the same. FIG. 1 shows a flow chart of the steps toperform on a payer's and a merchant's mobile device to communicatepayment information between the mobile devices using an animated 2Dbarcode check according to one or more embodiments of the presentdisclosure.

Before using the mobile devices to conduct payment transactions, usersof the mobile devices register with an on-line payment service provider,such as PayPal. In step 101, a payer accesses the payment serviceprovider's website to register an account and to fund the account. Thepayer downloads a payment generation application from the paymentservice provider and installs it on the mobile device. The applicationmay be used by the payer to enter signature information for generating asigning key. The user may also use the application to enter financialinformation to be encoded into the animated 2D barcode.

In step 103, the payer launches the application to generate a signingkey or certificate for use on the 2D barcode check. The signingkey/certificate may follow the X.509, OpenPGP, or S/MIME standard. Aftergenerating the key/certificate, the payer transmits the key/certificateto the payment service provider for certification. The payment serviceprovider certifies the key/certificate and may embed additionalcapability notations into the key/certificate to restrict its use tocertain types of payment transactions. For example, the key/certificatemay be certified for use in payment transactions that do not exceed amaximum transaction amount or occur during a certain time period. Thecapability notations may be transmitted by the payment service providerback to the payer's mobile device.

In step 105, when the payer wishes to generate an animated 2D barcodefor use as a payment instrument such as a check, the payer launches theapplication to enter information on the payment transaction. Theinformation entered may include the name and account number of the payeeor merchant, the payment amount, the check number, etc. The payer signsthe check with the signing key/certificate that has been certified bythe payment service provider in step 103. The application combines theentered information with the signing key/certificate and information onthe payer such as the payer's name, account number to generate a check.

In step 107, the payer may use the application supplied by the paymentservice provider or another application to encode the check into aformat suitable for generating an animated 2D barcode. For example,information on the check may be divided into data segments where thedata segment size is determined by the data size of a single frame ofthe 2D barcode. This data segment size may be adjusted to accommodatethe display resolution of the payer's mobile device and/or the scanningresolution of the camera on the merchant's mobile device. Each segmentis encoded and converted into a frame of the sequence of 2D barcodes. Toenable the display of the sequence of the 2D barcodes, each frame of 2Dbarcodes may have a number indicating its order within the sequence offrames. The mobile device displays the sequence of 2D barcodes in a loopto generate the animated 2D barcode check.

For a merchant to receive and to verify the information encoded in theanimated 2D barcode check, the merchant also needs to register with thepayment service provider. In step 109, the merchant accesses the paymentservice provider's website to register an account. The merchant alsodownloads a payment verification application from the payment serviceprovider and installs it on the merchant's mobile device. Theapplication may be used by the merchant to read the information decodedfrom the animated 2D barcode check and to verify the validity of thesigning key/certificate. To guard against unauthorized or fraudulent useof the signing key/certificate, the merchant may download a certificaterevocation list (CRL) from the payment service provider. The CRL listsnon-expired signing keys/certificates that have been revoked and thatshould be rejected by the merchant. For example, CRL may list thekeys/certificates of mobile devices that were reported stolen or thekeys/certificates determined by the payment service provider to befraudulent. The payment service provider may update the CRL at a regularinterval, such as daily, to keep the CRL current. The application maycheck for updates to the CRL on the payment service provider's websiteand automatically download the latest CRL to the merchant's mobiledevice. After receiving a check, the merchant may compare the signingkey/certificate against the CRL to reject the check if thekey/certificate appears on the CRL.

In step 111, the merchant uses the camera on the merchant's mobiledevice to scan the animated 2D barcode check displayed on the payer'smobile device. The merchant may use existing 2D barcode reading softwareto capture and decode the sequence of 2D barcodes. Scanning may startfrom any frame of the sequence of 2D barcodes and may continue until allthe frames of the sequence have been scanned. Because each frame hasembedded data that indicates the frame's order within the sequence anddata that indicates the total number of frames in the sequence, the 2Dbarcode reading software may determine if all the frames have beenscanned. Each decoded frame represents one data segment of the check.Therefore, the 2D barcode reading software may reconstruct the checkfrom all the decoded frames of the sequence of 2D barcodes. Because theframe size of the 2D barcode may be tailored to the scanning resolutionof the camera on the merchant's mobile device, scanning is lesssensitive to variations in focus or alignment of the camera. Inaddition, because smaller frame size may be scanned and decoded fasterthan larger frame size, frame size may be adjusted to improve thescanning speed. After the check is reconstructed from the decodedframes, the data may be passed to the payment verification applicationfor verification and processing.

In step 113, the payment verification application verifies the validityof the signing key/certificate. For example, the signing/key may beverified using the RSA algorithm. The payment verification applicationalso verifies that the signing key/certificate is certified by thepayment service provider. If additional capability or notation isembedded into the key/certificate to restrict its use to certain typesof payment transactions, the payment verification application may verifythat the payment transaction satisfies the restriction. For example, thekey/certificate is verified to confirm that it has not expired or thatit is received during a valid time period, or that the payment amountdoes not exceed a maximum transaction amount. To guard againstunauthorized use, the payment verification application compares thekey/certificate against the CRL to reject the key/certificate if itappears on the CRL. Once the key/certificate is verified, theapplication may verify that other information, such as the paymentamount and the merchant name or account number on the check, is correct.The merchant may then accept the check if all the information iscorrect. The application may display a message or generate an audiblesignal to indicate that the check has been accepted.

The merchant may receive checks from one or more payers. In step 115,the merchant accesses the payment service provider's website to presentthe checks for payment. The merchant may launch the payment verificationapplication to transmit to the payment service provider the checks. Foreach check, the payment service provider verifies the key/certificate,the account number of the payer and the merchant, and that there aresufficient funds in the payer's account to cover the payment amount. Thepayment service provider transfers funds from the payer's account to themerchant's account to credit the merchant for the payment amount.

FIG. 2 shows a more detailed flow chart of steps 103, 105 of FIG. 1performed on the payer's mobile device for payer set up and signing keycertification by the payment service provider according to one or moreembodiments of the present disclosure.

In step 201, the payer registers an account with the payment serviceprovider to sign up for payment transactions conducted from a mobiledevice using animated 2D barcode checks. Registration may be performedin any suitable fashion, such as by accessing the payment serviceprovider's website and entering the required identification information.The payer may be asked to set up an account if one has not beenestablished, or if an account has been established, to fund the account.The payer may also be asked to enter additional identificationinformation, such as the phone number of the mobile device, financialinformation, billing address, security questions and answers, etc. Themobile device may be a smart phone (e.g., iPhone, Google phone, or otherphones running Android, Window Mobile, or other operating systems), atablet computer (e.g., iPad, Galaxy), personal digital assistant (PDA),a notebook computer, or various other types of wireless computingdevices. Communication with the payment service provider may be providedthrough the Internet and/or one or more intranets, wireless networks(e.g., cellular, wide area network (WAN), WIFI hot spot, personal areanetwork (PAN), Bluetooth), landline networks and/or other appropriatetypes of communication networks. As such, in various embodiments, thepayer's mobile device may be associated with a particular link (e.g., alink, such as a URL (Uniform Resource Locator) to an IP (InternetProtocol) address).

In step 203, the payer downloads a payment generation application fromthe payment service provider for installation on the mobile device. Thepayment generation application enables the payer to generate a signingkey and provides a user interface for the payer to communicate with thepayment service provider for certification of the signing key. Thepayment generation application also provides a user interface for thepayer to enter payment information and may call a 2D barcode generationsoftware to encode the payment information into an animated 2D barcode.

In step 205, the payer launches the payment generation application togenerate a signing key or certificate. The signing/certificate needs tobe certified by the payment service provider and is attached to a checkto allow a merchant to validate the check. The signing key/certificatemay follow the X.509, the OpenPGP, or the S/MIME standard. The signingkey/certificate is transmitted to the payment service provider forcertification in step 207. The payment service provider verifies thatthe payer's account is properly set up and funded, and certifies thesigning key/certificate. The payment service provider also embedscapability notations into the key/certificate to restrict its use. Suchnotations may restrict use of the signing key/certificate before anexpiration date, to a maximum payment amount per transaction, a maximumnumber of transactions, and/or a maximum total payment amount for alltransactions. For example, the signing key/certificate May have anexpiration date that is one week to three months from the date thesigning key/certificate is certified.

In step 209, the payment service provider transmits the capabilitynotations back to the payer's mobile device and indicates to the payerthat checking privileges have been granted. In step 211, the payerstores the signing key/certificate in the mobile device. Because thesigning key/certificate may have an expiration date, in step 213, thepayment generation application checks to see if the key is still valid.If the key/certificate has expired, the payment generation applicationprompts the payer to generate a new key/certificate. The payer mayreturn to step 205 to generate a new key/certificate for certificationby the payment service provider.

FIG. 3 shows a more detailed flow chart of steps 105, 107 of FIG. 1performed on the payer's mobile device for generating the animated 2Dbarcode check according to one or more embodiments of the presentdisclosure. The payer visits a merchant to purchase goods or services.To pay for the purchase, the payer may launch the payment generationapplication on the mobile device to compose a check.

In step 301, the payer enters information to compose a check. Theinformation may include the name and account number of the merchant, thepayment amount, the date, a check number, and notes about the paymenttransaction. Alternatively, the payer may receive information about themerchant and the payment amount from the merchant's mobile device. Forexample, the merchant may use a barcode generating software to generatea 2D barcode or an animated sequence of 2D barcodes that encodes thename/account number of the merchant and the payment amount. The payermay use a camera on the payer's mobile device to scan the 2D barcode(s)and may use 2D barcode reading software to capture and decode theinformation from the merchant. The decoded information may then beimported into the payment generation application for the payer tocompose the check. The payment generation application may fill ininformation about the payer on the check such as the payer's name andaccount number.

In step 303, the payer verifies that all the information for the checkis correct and signs the check with the signing key/certificate. Thepayment generation application combines the information for the checkwith the stored signing key/certificate into a signed data block. Instep 305, the payer uses the payment generation application or a 2Dbarcode generation software to divide the signed data block into datasegments suitable for encoding into a sequence of 2D barcodes. Thesigned data block may be divided because it exceeds the maximum datasize for encoding into a single frame of 2D barcode, or it may bedivided because the density of the encoded 2D barcode exceeds thescanning resolution of the camera on a mobile device. For example, whilethe QR code standard has a maximum data size of 2953 bytes, most phonecameras lack the resolution to scan the density of a QR code thatencodes this data size. Therefore, to accommodate the scanningresolution of a wide spectrum of camera phones, the size of the datasegments to be encoded into a frame of a 2D barcode may be reduced belowthe maximum data size. Alternatively, the size of the data segments maybe tailored to the scanning resolution of a camera, such as that of themerchant's mobile device. In addition, it may be advantageous to havesmaller data segments so that the smaller 2D barcode frames encoded fromthe smaller data segments are less sensitive to variations in focus oralignment of the camera. Smaller 2D barcode frames are also read anddecoded faster. Each data segment is encoded into a frame of thesequence of 2D barcodes. The data segment may be prefixed with anotation to indicate its frame number and the total number of frames inthe sequence. For example, the data segment may have a “2 of 5” prefixto indicate that it is the second of a sequence of five frames of theanimated 2D barcode.

In step 307, the data segments are encoded and converted into frames ofthe sequence of 2D barcodes. In step 308, payer's mobile device displaysthe sequence of 2D barcode frames in a continuous loop to generate theanimated 2D barcode check. The time that each frame of the 2D barcode isdisplayed may be adjustable to accommodate the speed of the camerascanning the animated 2D barcode. For example, the mobile device maydisplay each 2D barcode frame for a period of 100-1000 ms. In step 311,the payer presents the animated 2D barcode check to the merchant forscanning.

FIG. 4 shows a frame of an animated 2D barcode generated from a payer'smobile device according to one or more embodiments of the presentdisclosure. The mobile device displays fields for the payer to enter amerchant name 401, a merchant's account number 403, a payment amount405, and a check number 407. The payment generation application combinesthe entered information with information on the payer and a signingkey/certificate to generate a signed data block of a check. The signeddata block is segmented, encoded, and converted into frames of theanimated 2D barcode for display in a continuous loop. A frame 409 of theanimated 2D barcode is shown.

FIG. 5 shows a detailed flow chart of step 109 of FIG. 1 performed on amerchant's mobile device to communicate with a payment service providerto register an account and to receive a certificate revocation list(CRL) according to one or more embodiments of the present disclosure. Instep 501, the merchant registers an account with the payment serviceprovider to sign up to accept animated 2D barcode checks as payments.The merchant may register a mobile device such as a smart phone toreceive 2D barcode checks. Alternatively, the merchant may use apoint-of-sale (POS) terminal, or other types of computing devices as ahardware platform for receiving 2D barcode checks.

In step 503, the merchant downloads the payment verification applicationfrom the payment service provider for installation on the mobile device.The payment verification application enables the merchant to verify thevalidity of the signing key/certificate received from the payer andprovides a user interface for the merchant to interact with the paymentservice provider. Because the merchant may verify the signingkey/certificate without having Internet connectivity to the paymentservice provider, the CRL enables the merchant to recognize signingkeys/certificates that should be rejected by the merchant when offline.For example, CRL may list the keys/certificates of mobile devices thatare reported stolen or the keys/certificates determined by the paymentservice provider to be fraudulent. The payment service providermaintains the CRL and may update the CRL on a regular basis, such asdaily, to keep the CRL current. In step 505, the merchant downloads themost current CRL from the payment service provider into the paymentverification application. To keep the CRL on the mobile device current,in step 507, the payment verification application may automaticallycheck for updates to the CRL on a periodic basis when the mobile deviceis online. If the CRL on the mobile device is out of date, the paymentverification application downloads the most current CRL from the paymentservice provider.

FIG. 6 shows a detailed flow chart of steps 111, 113 performed on amerchant's mobile device to scan and validate the animated 2D barcodecheck according to one or more embodiments of the present disclosure. Instep 601, the merchant uses the camera and 2D barcode reading softwareon his/her mobile device to scan the sequence of 2D barcode checkdisplayed on the payer's mobile device. Alternatively, the merchant mayuse a CCD scanner attached to a mobile device. Because the sequence of2D barcodes is played in a continuous loop, scanning may start from anyframe of the sequence until all frames of the sequence have beenscanned. In step 603, the software determines if all frames in thesequence have been scanned. For example, the software may read anddecode the prefix information from each frame that indicates the framenumber and the total number of frames in the sequence. If the prefixinformation shows there is still more frame to scan, step 601 is invokedto scan the remaining frame. In addition, if the scanned frame has adecoding error, the software may re-scan the frame in step 601. In step605, the software decodes and converts the scanned frames into datasegments. In step 607, the software reconstructs the data segments usingthe prefix information into the signed data block of the check thatincludes the information for the check and the signed key/certificate.The reconstructed check may be passed to a payment processing layer ofthe payment verification application for processing.

In step 609, the payment processing layer verifies the signedkey/certificate. For example, the payment processing layer may verifythat the signed key/certificate is valid using the RSA algorithm andthat it is certified by the payment service provider. The paymentprocessing layer may also check the capability notations embedded intothe signing key/certificate to verify that the signing key/certificateis valid for use with the payment transaction, e.g., that the signingkey/certificate has not expired, that the payment amount does not exceedthe maximum transaction amount, and/or that a maximum number oftransactions has not been exceeded. Additional verification may includeverifying that the payment amount and the merchant name, account numberare correct. If the verification fails, the merchant rejects the checkin step 613. The merchant's mobile device may display a messageindicating that the check is rejected and the reason for the rejection.The merchant's mobile device may also send a message to the payer'smobile device about the rejection.

If the verification is successful, in step 611, the payment processinglayer compares the signing key/certificate against the CRL to verifythat the signing key/certificate is not on the CRL. The CRL listssigning keys/certificates that are revoked but are otherwise valid. Asdiscussed earlier, the CRL may list the keys/certificates of mobiledevices that are reported stolen or those determined by the paymentservice provider to be fraudulent. If the signing key/certificateappears on the CRL, the merchant rejects the check in step 613.Otherwise, the merchant accepts the check in step 615. The merchant'smobile device may display a message indicating that the check isaccepted, or may send a message to the payer's mobile device indicatingso. Note that because the CRL is only updated by the payment serviceprovider on a periodic basis and downloaded to the merchant's mobiledevice only when there is Internet connectivity, the signingkey/certificate of a recently stolen mobile device may not appear on theCRL in time for the merchant to reject the check received from thestolen mobile device. In this case, when the merchant presents theaccepted check to the payment service provider for payment in step 115,the payment service provider may determine that the signingkey/certificate should have been rejected. The payment service providermay accept the check and write off the amount based on the governingprotection rules for the benefit of the merchant.

Although the above description focuses on using a sequence of 2Dbarcodes for a payment transaction, it will be appreciated that the ideaof storing and communicating large amounts of data using two or moredifferent barcodes in sequence is not limited to just financialtransactions. In various embodiments, any type or use requiringcommunication of large amounts of data can employ ideas containedherein, where smaller amounts of data are stored and communicated ineach barcode in a sequence, with the total sequence communicating thecomplete message or information. Furthermore, use need not be limited tomobile devices.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the spirit of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components, andvice-versa.

Application software in accordance with the present disclosure, such asprogram code and/or data for generating, receiving, or verifying the 2Danimated barcode may be stored on one or more non-transitory computerreadable mediums. It is also contemplated that the application softwareidentified herein may be implemented using one or more general purposeor specific purpose computers and/or computer systems, networked and/orotherwise. Where applicable, the ordering of various steps describedherein may be changed, combined into composite steps, and/or separatedinto sub-steps to provide features described herein.

Although embodiments of the present disclosure have been described,these embodiments illustrate but do not limit the disclosure. It shouldalso be understood that embodiments of the present disclosure should notbe limited to these embodiments but that various alternate embodimentsand/or modifications to the present invention, whether explicitlydescribed or implied herein, are possible in light of the disclosure.For example, other types of payment instruments such as credit cards,debit cards, gift cards, coupons, or other types of financialtransactions such as issuance of refunds or credits may be communicatedusing 2D animated barcode. In addition, devices other than mobiledevices may also use 2D animated barcode to conduct financialtransactions.

Having thus described embodiments of the invention, numerousmodifications and variations may be made by one of ordinary skill in theart in accordance with the principles of the present disclosure and beincluded within the spirit and scope of the present disclosure ashereinafter claimed.

1-21. (canceled)
 22. A system, comprising; at least one processor; andat least one memory device storing computer-executable instructionsthat, in response to execution by the at least one processor, cause thesystem to perform operations comprising: receiving data associated withpayment information for a payment instrument; dividing the data into aplurality of data segments; encoding each of the plurality of datasegments to a respective two-dimensional barcode of a plurality oftwo-dimensional barcodes; assigning a sequential identifier to eachbarcode of the plurality of two-dimensional bar codes; and sequentiallydisplaying the plurality of two-dimensional barcodes by displaying eachof the plurality of two-dimensional barcodes individually as acurrently-displayed barcode and subsequently replacing thecurrently-displayed two-dimensional barcode with a next two-dimensionalbarcode in accordance with the sequence identifier.
 23. The system ofclaim 22, wherein the encoding the data includes encoding each of thedata segments according to a pre-determined maximum segment size. 24.The system of claim 22, wherein the dividing the data into the pluralityof data segments comprises dividing the data according to categories ofdata.
 25. The system of claim 22, wherein the dividing the data into theplurality of data segments comprises dividing the data according to apre-determined number of data segments.
 26. The system of claim 22,wherein the sequentially displaying the plurality of two-dimensionalbarcodes initiates a payment transaction using the payment instrument.27. The system of claim 22, wherein the sequentially displaying theplurality of two-dimensional barcodes initiates a refund transactionusing the payment instrument.
 28. The system of claim 22, wherein thereceiving the data associated with the payment information includesreceiving information comprising a merchant name, an account associatedwith a user, and a signing certificate.
 29. A method, comprising:receiving data associated with payment information for a paymentinstrument; dividing the data into a plurality of data segments;encoding each of the plurality of data segments to a respectivetwo-dimensional barcode of a plurality of two-dimensional barcodes;assigning a sequential identifier to each barcode of the plurality oftwo-dimensional bar codes; and sequentially displaying the plurality oftwo-dimensional barcodes by displaying each of the plurality oftwo-dimensional barcodes individually as a currently-displayed barcodeand subsequently replacing the currently-displayed two-dimensionalbarcode with a next two-dimensional barcode in accordance with thesequence identifier.
 30. The method of claim 29, wherein the encodingthe data includes encoding each of the data segments according to apre-determined maximum segment size.
 31. The method of claim 29, whereinthe dividing the data into the plurality of data segments comprisesdividing the data according to categories of data.
 32. The method ofclaim 29, wherein the dividing the data into the plurality of datasegments comprises dividing the data according to a pre-determinednumber of data segments.
 33. The method of claim 29, wherein thesequentially displaying the plurality of two-dimensional barcodesinitiates a payment transaction using the payment instrument.
 34. Themethod of claim 29, wherein the sequentially displaying the plurality oftwo-dimensional barcodes initiates a refund transaction using thepayment instrument.
 35. The method of claim 29, wherein the receivingthe data associated with the payment information includes receivinginformation comprising a merchant name, an account associated with auser, and a signing certificate.
 36. A non-transitory machine-readablemedium comprising instructions which, in response to a computer system,cause the computer system to perform operations comprising: receivingdata associated with payment information for a payment instrument;dividing the data into a plurality of data segments; encoding each ofthe plurality of data segments to a respective two-dimensional barcodeof a plurality of two-dimensional barcodes; assigning a sequentialidentifier to each barcode of the plurality of two-dimensional barcodes; and displaying, using the assigned sequential identifier, theplurality of two-dimensional barcodes in a continuous loop on a userdevice.
 37. The non-transitory machine-readable medium of claim 36,wherein the encoding the data includes encoding each of the datasegments according to a pre-determined maximum segment size.
 38. Thenon-transitory machine-readable medium of claim 36, wherein the dividingthe data into the plurality of data segments comprises dividing the dataaccording to categories of data.
 39. The non-transitory machine-readablemedium of claim 36, wherein the dividing the data into the plurality ofdata segments comprises dividing the data according to a pre-determinednumber of data segments.
 40. The non-transitory machine-readable mediumof claim 36, wherein the sequentially displaying the plurality oftwo-dimensional barcodes initiates a payment transaction using thepayment instrument.
 41. The non-transitory machine-readable medium ofclaim 36, wherein the sequentially displaying the plurality oftwo-dimensional barcodes initiates a refund transaction using thepayment instrument.